home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group94a.txt / 000105_icon-group-sender _Wed Apr 27 08:48:03 1994.msg < prev    next >
Internet Message Format  |  1994-08-19  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Wed, 27 Apr 1994 09:01:12 MST
  2. Date: Wed, 27 Apr 94 08:48:03 PDT
  3. From: kwalker@sirtur.premenos.com (Ken Walker)
  4. Message-Id: <9404271548.AA01384@sirtur.premenos.com>
  5. To: icon-group@cs.arizona.edu
  6. Subject: Re: tables, lists, and memory question
  7. X-Sun-Charset: US-ASCII
  8. Content-Length: 1871
  9. Status: R
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11.  
  12. > From: "Art Eschenlauer" <eschen@molbio.cbs.umn.edu>
  13. > 
  14. > 
  15. > I've been wondering for some time now about how (if) Icon knows what
  16. > things to trash.
  17.  
  18. Icon does its own storage management within the memory it malloc()s. When
  19. it does not have room to allocate an object within the memory it has, it
  20. performs a garbage collection to try to recover unused space before it
  21. malloc()s more memory. To perform garbage collection, it starts from a
  22. "basis" of locations that the Icon program can access, for example, the
  23. program's variables, marking things that can be reached. For data types with
  24. pointer semantics, it follows pointers until it reaches an end or reaches
  25. something that has already been marked. When it has marked everything that
  26. the program might use in the future, it can "free" everything else and
  27. compact its allocated memory, relocating pointers to objects it moves.
  28.  
  29. Icon's garbage collection is not perfect, but it is conservative. It may
  30. save a few things it doesn't need to. There is a rather subtle example.
  31. If I remember correctly, it is something like:
  32.  
  33. procedure p()
  34.    local c
  35.  
  36.    c := create write("Hi")
  37.    c := create write("Bye")
  38.    # do something that causes garbage collection
  39. end 
  40.  
  41. Internally, the second co-expression get a copy of the variable c with
  42. a reference to the first co-expression even thought it doesn't use the
  43. variable c. There is no way to activate the first co-expression, but
  44. the garbage collector will save it. Dispite a few holes like this, the
  45. Icon interpreter is pretty good about only keeping things that might still
  46. be accessed by the Icon program. The Icon compiler is a little sloppier
  47. about it. It may leave things in temporary variables that are no longer
  48. needed and the garbage collector will assume that they are needed. However,
  49. in practice this doesn't seem to be a problem.
  50.  
  51.    Ken Walker, kwalker@premenos.com
  52.